Partial Boundary
参考
図解
https://gyazo.com/f21d4381e067026077ec6475000775d4 https://twitter.com/syobochim/status/1525431520076234752
WIP
---------------
例
最後のステップを省略する
片方だけの境界
Facadeパターン
序盤にBoundaryを作ることはオーバーエンジニアリングとみなされることもあるが、後からBoundaryを作ることのコストは実際大きい
将来を見越しながら、どのレベルのBoundaryを用意すべきかを常に検討する必要がある
『Clean Architecture』.icon 24章では3つ段階が例として紹介されている
最後のステップを省略する
同一のComponentの中に存在はするが、内部では厳格に境界が区切られている
言うなれば、今すぐにでも物理的にシステムを独立させても耐えるぞ、という状態
「最後のステップの省略」とは、「あとはCompoentを分けるだけ」ということ
Componentには分かれていないので、「部分的な境界」であると言える
マイクロサービス的な辛みを受けないことがメリット
3つの中では最もコストが高い
片方だけの境界
https://gyazo.com/b4bd75a8e23e66df2edc8469672a57d8
Client → Interface ← Implのように、片側だけInterfaceを用意する
DIPは達成できている
問題は上記の点線のような境界の違反を防ぐすべがないこと
https://gyazo.com/7d416fe33d193e9b53cb1aa69e3163b6
Facade classが境界としてギリ存在している
Interfaceの仲介などを特にしていない
各Serviceの実装が変更されると、Clientも再compileが必要になる
3つの中では最も緩い
実際はもっと色々な境界の作り方とそのレベルが存在するだろうmrsekut.icon 深掘りする価値がありそう
境界の作り方にはレベルがあることを認識する
それぞれの作成・メンテコストを考える
どういう判断でそのレベルを選択するのかを考える
将来に備える v.s. 将来に備えすぎない、のトレードオフ
https://gyazo.com/f377952168dd936ae877381cbe1b903f https://techblog.lycorp.co.jp/ja/designing-software-like-an-open-source
moduleの構成の分類
もっとありそう